home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20000114-20000217 / 000168_news@columbia.edu _Thu Jan 27 21:28:16 2000.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id VAA25412
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Thu, 27 Jan 2000 21:28:16 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id VAA02370
  7.     for kermit.misc@watsun.cc.columbia.edu; Thu, 27 Jan 2000 21:01:40 -0500 (EST)
  8. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Subject: Re: Case Study #10: Atomic File Movement
  11. Date: 28 Jan 2000 02:01:39 GMT
  12. Organization: Columbia University
  13. Message-ID: <86qta3$2a0$1@newsmaster.cc.columbia.edu>
  14. To: kermit.misc@columbia.edu
  15.  
  16. In article <gSF8krj$2SXn@cc.usu.edu>, Joe Doupnik <jrd@cc.usu.edu> wrote:
  17. :     A "friendly amendment." While the Kermit protocol, and TCP, do an
  18. : acceptable job of confirming stages of work are completed, those techniques
  19. : do not remove ambiguity. Frank correctly states "somewhat immune." Old
  20. : packets whose sequence numbers have wrapped to the proper current value,
  21. : badly garbled ones with apparently legit contents (CRC checks are hardly
  22. : perfect), and packets delivered by mistake to the wrong session, are three
  23. : serious concerns for protocol designers because they confuse the normal 
  24. : stage by stage confirmations. TCP uses three way handshakes, extra steps
  25. : to extend sequence numbers in some circumstances, and pseudo headers, to
  26. : help reduce false indications. Kermit does a pretty good job too, but not
  27. : to the extent that TCP goes. 
  28. :     The two hill army problem remains when one gets serious about comms.
  29. : As stated, there is no certainty in the exchange, only approximation to it.
  30. :      
  31. I meant to get back to this earlier, (so as not to leave an unsettling
  32. impression with readers who don't study these topics) but better late than
  33. never.
  34.  
  35. I believe most of Joe's observations pertain more to TCP and IP than to
  36. Kermit:
  37.  
  38.  . Old packets whose sequence numbers have wrapped.  This can happen in
  39.    TCP/IP because it's a worldwide packet-switched network.  A TCP packet
  40.    (encapsulated within an IP packet) can be stuck in the network for
  41.    minutes, hours, days, or weeks, and then show up after the sequence
  42.    number space has recycled one or more times, and then it can cause
  43.    trouble unless there is a higher (than TCP) level of checking.  But
  44.    Kermit connections are either point-to-point in fact, or in effect, so
  45.    packets don't lurk in odd crannies of the world and reappear at a later
  46.    time -- at least not late enough to cause confusion about packet
  47.    numbers.  Why?  Because (in the non-streaming case) every Kermit packet
  48.    must be acknowledged.  The window can't be larger than half the
  49.    sequence number space, and it can't advance until the oldest packet in
  50.    the window is acknowledged.  This technique, called "sliding windows
  51.    with selective retransmission", is more conservative and robust than
  52.    the technique TCP uses in preventing packet sequence number ambiguity.
  53.  
  54.  . Packets are delivered by mistake to the wrong session.  Can't happen in
  55.    Kermit because there is only one session.
  56.  
  57.  . Packets can be garbled to look like other packets.  Yes, this can
  58.    happen in any communictions protocol with some calculable probability.
  59.    But let's look at the consequence in the context of atomic file
  60.    movement.  First, it is possible (but highly unlikely) that a data
  61.    packet can be corrupted in such a way that its CRC will still be
  62.    correct, thus allowing bad data into a file (but only if the packet
  63.    sequence number, length, and other controls remain valid).  Of course
  64.    this can happen in any communications protocol; there is a whole
  65.    literature on the subject.  But what about the progress of the protocol
  66.    itself?  Each possible happenstance and its consequences can be
  67.    examined in turn.  For example, an ACK can turn into a NAK with the
  68.    same sequence number.  No harm is done.  A NAK can turn into an ACK for
  69.    the same packet.  Again, no harm is done (because the seemingly ACK'd
  70.    packet will missing at the receiver, and this will cause the transfer
  71.    to fail eventually.)  An ACK is turned into something besides an ACK or
  72.    NAK: then we have an illegal packet type and the transfer fails.  An
  73.    ACK is turned into an ACK with a different sequence number; if it's an
  74.    "old" sequence number it is ignored and no harm is done; if it's a
  75.    "new" one, the sender will catch the error ("You ACK'd a packet I didn't
  76.    send").  And so on.
  77.  
  78. In other words, I think it is safe to say that the chances are practically
  79. negligible that a Kermit transfer will appear to succeed when it failed.
  80. Except perhaps for possible data corruption, which all protocols are subject
  81. to; as noted in the literature, the number of errors that a CRC will not
  82. catch is very small, and the probability that exactly such an error will
  83. occur, out of all the kinds of errors that can occur, is much smaller still.
  84.  
  85. And in fact, in 20 years of experience with Kermit transfers, I can't recall
  86. a single confirmed report of the protocol reporting success when the
  87. transfer failed.
  88.  
  89. - Frank